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ABSTRACT 


TwiddleNet leverages on smart phones to facilitate information sharing among 
first responder teams during humanitarian aid and mass casualty scenarios. Situational 
awareness and relief efforts coordination can thus be derived from the timely and shared 
information. In view of large-scale disaster relief efforts, TwiddleNet is likely to operate 
in multiple sites with unique network establishments. The thesis focuses on testing 
various scenarios for cross-network, information-sharing operations. A new architecture, 
based on the study of the Nokia Mobile Server concepts and existing TwiddleNet 


operating models, is suggested in the thesis as well. 
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I. INTRODUCTION 


TwiddleNet leverages the mobility of handheld wireless communication devices 
to reach out to any operation site with the objective of creating situation awareness. It is 
most useful for first-responder networking and information-sharing tasks that require 


immediate content capture and dissemination [1]. 


In 2005, the Category 5 hurricane, Katrina, caused severe destruction over 90,000 
square miles of Louisiana and Mississippi. As the affected area was vast, there was a 
need for multiple responder teams (firefighters, police officers, medics) to be deployed 
over different disaster sites. Under such situations, it is only logical that information 
should be shared among the responder teams within and between sites throughout the 
entire operation. This would facilitate comprehensive situational awareness for better 
decision making and resources TwiddleNet is, therefore, a useful tool for deployment in 
this type of operation. However, TwiddleNet must be able to deploy at multiple sites to 
cover the ranges beyond the reach of a single site. This means that TwiddleNet must be 
able to operate across networks for information sharing. By allowing TwiddleNet to share 
information across networks, it will expand the capability of TwiddleNet to operate over 


a longer range and in larger areas of operation. 


In deploying TwiddleNet across multiple networks, there is a high possibility that 
it will ride on established networks. Therefore, it is also important that the architecture of 


TwiddleNet have the flexibility to configure and work with the existing infrastructure. 
De OBJECTIVES 


The aim of this thesis is to expand the existing TwiddleNet architecture for use in 
a multi-network environment and conduct tests to verify that this architecture can 
perform cross-network information sharing. Given the fact that TwiddleNet uses wireless 
IP-based architecture, TwiddleNet can be deployed across multiple networks that have 


access points to connect to. Investigations will determine the possibility of sharing 


information among TwiddleNet clients residing in different networks. Commercial off- 
the-shelf implementation will be explored in this thesis to bridge any gaps for cross- 


network information sharing. 


This thesis will also perform a study of the Nokia Mobile Web Server and 
propose a possible future architecture for TwiddleNet. This architecture will combine the 
good features of both the Mobile Web Server and TwiddleNet, and, hopefully, will also 


eliminate the shortcomings of TwiddleNet. 
B. RESEARCH QUESTIONS 


The thesis will try to address the following research questions. 1) Is the existing 
TwiddleNet Architecture suitable for use in a multi-network environment? 2) How can 
information be stored and disseminated across different networks? 3) What are the best 
techniques to achieve information sharing across different networks using existing 
TwiddleNet Architecture? 4) Is there a need for totally new TwiddleNet architecture and 


concepts given the current technology trends? 
be SCOPE AND METHODOLOGY 


There are two major scopes for the thesis. The first major scope will focus on 
reviewing the TwiddleNet system architecture and expanding the system capabilities to 
allow cross-network information sharing. Efforts are concentrated on reviewing the 
current TwiddleNet system architecture to determine gaps for cross-network information 
sharing. TwiddleNet system architecture is then evaluated for cross-network sharing 
feasibility. Given the advancement of technologies and trends in the last couple of years, 
this research hopes to bring together the next generation of TwiddleNet architecture. The 


thesis research will be conducted in three distinct phases. 


1 Bs Phase 1: Review of Current System Architecture 


The first phase reviews the existing TwiddleNet system architecture. This 
involves reviewing the hardware configuration, network and software designs. The 
purpose is to identify technical shortfalls in the system for cross-network information 


sharing. 
2. Phase 2: Test and Evaluate 


Once the gaps in the system are identified, the next step is to research and design 
a solution to bridge the gaps. Subsequently, testing and evaluation can be done to verify 


the feasibility of cross-networking content sharing. 


35 Phase 3: Propose a New Architecture for the Future Generation of 
TwiddleNet 


TwiddleNet has been in operation for over two years. In the meantime, new 
technologies and wireless content-sharing concepts have evolved extensively. The final 
phase of the thesis will involve the study of current technologies. A new architecture for 


the next generation of TwiddleNet is then proposed following the study outcomes. 
D. ORGANIZATION 


This thesis is structured according to the following topics: 


Chapter II explains the current architecture of TwiddleNet. TwiddleNet system 
components: Portal, Command Center and Mobile Clients roles and modes of operations 


are discussed. The limitations of the existing architecture are highlighted as well. 


Chapter III discusses some design considerations for TwiddleNet to be deployed 


in multiple networks. 


Chapter IV explains various test setups to verify the possibility of TwiddleNet to 


operate on multiple networks where cross-network information sharing can be achieved. 


Chapter V proposes the next generation of TwiddleNet using Mobile Web Server 
concepts to bridge the existing gaps. The new TwiddleNet will harness all the desirable 
features of Mobile Web Servers and existing TwiddleNet to serve as a more effective tool 


for its intended purposes. 


Chapter VI concludes this thesis with the findings from various lab and onsite 


testing. 


E. BACKGROUND 


Existing TwiddleNet architecture allows real-time information to be shared 
seamlessly between TwiddleNet hosts within a single network. This architecture has a 
restriction for operating over a large area as the range of deployment is as far as a single 
network can reach. In responding to an emergency situation such as a hurricane, 
TwitterNet is likely to deploy TwiddleNet at different networks that are interconnected to 
cover a large affected area. As such, situational content sharing can only be fulfilled if 
TwiddleNet is able to operate in a multi-network environment. The ability to share 
information across different networks will greatly enhance the usefulness of TwiddleNet 


in humanitarian aid and disaster relief operations. 


TwiddleNet uses wireless IP-based architecture. Initial assessment is that there are 
no or only minor modifications required to the TwiddleNet application to allow it to 
interoperate with standard TCP/IP protocol for cross-network information sharing. As the 
Portal application manages the flow of information between all hosts, the key focus is to 
understand the Portal processes, to determine the changes required on the architecture 


that would allow hosts to send information across networks. 


The Portal has three basic responsibilities within the TwiddleNet architecture [4]: 
(1) to store and process metadata (2) to service file request (3) to alert subscribers to any 
new content. The Portal application participates as a mid-tier in all communications 
between the content providers and the subscribers. When a content provider shares 
information, there are two possible scenarios [2] that could happen. They are: (1) Client 
serving: the content owner will provide the content to the requesting content subscribers. 


Portal will direct all requests to the mobile client who owns the content. (2) Portal 
4 


Caching: Portal will temporarily cache the content shared by the content owner. All 
downloading requests are served by the Portal instead of the mobile client who owns the 
content. In both cases, the Portal will have to uniquely identify both the content providers 
and subscribers. In another words, the Portal must be able to resolve the IP to a legitimate 


mobile client, regardless of which network the mobile client resides on. 
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I. CURRENT ARCHITECTURE AND GAPS 


A. TWIDDLENET ARCHITECTURE 


The TwiddleNet system is comprised of three key components: Portal, Command 
Center and Clients. These three components are connected together in a Wireless Local 
Area Network (WLAN) via an Access Point as shown in Figure 1. The Portal and 
Command Center are statically deployed, and the clients are the only mobile components 
to be used at the area of operations. The clients are also the originators of the contents for 
sharing within the WLAN. When the TwiddleNet application is launched from a client, it 
will require the client to register with the Portal. The purpose is to allow the Portal to 
keep track of the clients in the network for receiving and forwarding of messages. The 
Command Center stores all the information sent from the clients and displays it in a Web 
page. The consolidated information in the Command Center can be used by the 
Commander for decision making. The detailed operation of each component is described 


in Figure 1. 





Portal 





Command Center 





Clients 


Figure 1. | Overview of TwiddleNet Connectivity 
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1. Portal 


The Portal is the heart of the TwiddleNet and should be the first component to set 
up. Without the Portal, the clients and the Command Center will not be able to function 
properly. The Portal has a database that stores the user account and passwords for 
authentication. It also keeps track of all the registered clients. Therefore, a user must first 
login to the Portal through the TwiddleNet application running on the client, in order to 
identify him as an authorized user. Upon successful login, the Portal will keep track of 
the IP address of the client. As such, the Portal will have a list of all the IP addresses of 
the clients that have registered to it. If a client has captured a picture for sharing, the 
Metadata of the picture will be sent to the Portal. The Portal will then forward the 
information to other clients, directing them to download the picture from the content 


provider. 
2. Command Center 


The Command Center is an integral part of the system for the Commander. It 
provides a collection of all the content sent by all the Clients for the Commander to make 
decision in an operation. It is also a service provider for authorized systems to connect to 
it to view the Command Center information. Similar to the Client, the Commander 
Center is also required to register with the Portal in order to receive information updates 
from the Clients. However, there is no need for man-in-the-loop to download the picture 
from the content provider. The application running at the Command Center will perform 
the downloading automatically. The pictures downloaded are then displayed on a 
webpage hosted at the Command Center. Subsequent downloaded pictures are then 
appended to the list of pictures in the webpage. The Command Center is also able to tag 
additional information to the picture received. However, this information is not sent out 
to the network and can only be viewed by authorized systems that access the Command 


Center. 


3. Clients 


The Clients are used by the users to capture and share information. In order to use 
the TwiddleNet application, clients need to be identified by an IP address. IP address can 
be obtained either by enquiring a DHCP server or by a static IP address configuration. 
During deployment, the system has the flexibility to connect itself to a DHCP Server 
from another Organization in the network. The system can also set up its own DHCP 
Server for its clients to connect to. In the lab set up, the Command Center is also a DHCP 
Server. Once the client has an IP address and has a link to the Portal, it can launch the 
TwiddleNet application. The application will first lead the user to logon to the Portal with 
a valid user account and password. Upon successful logon, the client IP address will be 
registered with the Portal. When a user captures a picture of an incident using the camera 
of the mobile device, the application will automatically send out the Metadata of the 
picture to the Portal. The Portal will then forward the information to other clients. When 
other clients received this information in a form of an alert message, they can download 


the picture from the originator directly. 


B. GAPS 


1. Range 


The Portal, Command Center and Clients are connected via an Access Point. 
While specialized access points can provide a coverage of several hundreds of meters, a 
typical Access Point can support to a radius of 100m [6]. This means that Portal, 
Command Center and Clients have to operate at a radius no longer than 100m. In some 
cases, this may not be very practical. For example, Fireman may be divided into two 
teams to fight forest fire at two locations. The two locations are more than 200m apart 
and both teams are reporting to the same Command Center. Since the operating range of 
the Access Point cannot reach both locations at the same time, the two teams of Fireman 
are not able to share information. This constraint will restrict the practically of the use of 


TwiddleNet beyond the range of the Access Point. Content sharing within a 100m radius 


may not be meaningful as all teams share the similar views. Whatever all teams can see 
is also visible to the Command Center. As such, sharing of information to each other 


within a 100m range may not be necessary. 
2. Cross Network Information Sharing 


TwiddleNet is designed and tested on single network architecture. The transaction 
of message from one node! to another is within the same network. There is no 
requirement for the message to route from one network to another to reach and 
destination node and vice versa. In order to implement TwiddleNet on multiple networks, 
there is a need to perform study and conduct tests to verify cross network information 
sharing is possible. One possible way of implementing cross network information sharing 
is to implement Inter-WLAN connection as shown in Figure 2. If one team has to deploy 
beyond the range of TwiddleNet WLAN, the team can set up its own WLAN or connect 
to an existing remote WLAN. Then link the remote WLAN to the TwiddleNet WLAN 
through WAN or Internet. However, one constraint to this configuration is that all the 
clients at the remote WLAN must not have conflicting IP addresses with the TwiddleNet 
WLAN devices. The situation of conflicting IP addresses is likely to happen as Service 
Providers or agencies providing the WLAN are likely to use private IP addresses to 
manage their own network devices. There are chances that the IP addresses allocated to 
the clients at the remote WLAN are the same as the IP addresses allocated at the 
TwiddleNet WLAN. In this case, the concept of remote WLAN to extend the range of 
TwiddleNet will not work. 


! Refer to Client, Command Center or Portal. 
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Figure 2. TwiddleNet Inter-WLAN Connectivity 
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Il. DESIGN CONSIDERATIONS FOR TWIDDLENET 
ARCHITECTURE TO ALLOW CROSS NETWORK INFORMATION 
SHARING 


The purpose of the new architecture TwiddleNet design is to extend the capability 
to allow it to operate in more than one network. Such capability will enable the Response 
Team to operate in areas beyond the coverage of a single network. In fact, the Response 
Team should have the flexibility to operate in any network that has a linkage to the 
Command Center. As such, the design of TwiddleNet has to be carefully thought through 
so that the requirements can be met and yet the fundamental characteristics of the system 
will not be affected. The following are the general design considerations for the 


TwiddleNet: 


A. PORTABILITY 


One of the key benefits of TwiddleNet is that it is portable. It allows a small team 
to carry and deploy in area of operations easily without the need of heavy machinery or 
massive manpower. The overall size and weight of all the equipment is also small enough 
to be carried by many types of transportation. As such, any additional device added to 
TwiddleNet to allow cross-network information sharing should not affect its 
characteristics of portability. The overall size and weight of TwiddleNet should not 
increase significantly with the additional devices. Consequently, deployment 


considerations should remain the same for the new TwiddleNet architecture. 


B. SIMPLICITY 


TwiddleNet uses only a few portable devices for deployment. This allows the 
entire system to be set up easily, even by one person. Half-day training is also sufficient 
to allow a person to have the knowledge to deploy the system without guidance. This also 
implies that the transfer of knowledge for sustainability is simple. Therefore, the new 
architecture of TwiddleNet should not transform a simple system into a complex one. The 


system should continue to be simple to set up and configure. It should be easy to manage 
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such that a person should not take more than 20 minutes to complete the entire set up. 
The system should also allow tests to be performed easily to verify for correctness. 
Finally, the new TwiddleNet architecture should require no steep learning curve in order 


to operate it. 


C. FLEXIBILITY 


The nature of each operation is different and the system should be able to 
configure accordingly to support each of them. The system should have the flexibility to 
configure with a standalone network or ride on an established network set up by another 
Organization. For example, the system may ride on the network established by the U.S. 
Navy in the area of operations for communication back to the Command Center. 
Alternatively, the system can be set up as a standalone network for communication if 
there is no other available network to ride on. As such, the system should have the 
flexibility to configure to work on the best available network infrastructure. In addition, 
the system should have the flexibility to configure to work on more than one network. 
The clients may be configured and distributed in separate networks and yet able to 


communicate with each other, and with Portal, as if they are sitting on the same network. 


D. COMPATIBILITY 


The next generation of TwiddleNet will be using the current version of 
TwiddleNet as a baseline to develop a subsystem for cross-network information sharing. 
The design of the subsystem must be compatible with the baseline, such that there should 
be no interoperability issues. The subsystem should use the same protocol as the baseline 
for message exchanges and a converter should not be required to perform the conversion 
of these messages. In addition, there should not be any proprietary application required to 
access the data in the Command Center. A remote terminal should be able to access the 
webpage hosted in the Command Center using a common browser such as Internet 


Explorer. 


14 


E. MAINTAINABILITY 


TwiddleNet uses Commercial-Off-The-Shelf (COTS) devices, which do not 
require frequent maintenance. These devices can also be easily replaced by equivalent 
models from the commercial market. In addition, there is minimum caching in the 
application and it does not need regular housekeeping. The design of the next version of 
TwiddleNet will continue to take the same approach to reduce the risk of obsolescence by 
using hardware that is easily available and replaceable from the commercial market. In 
addition, the application will adopt minimum caching and configuration to minimize the 


need for housekeeping. 


F. COST 


TwiddleNet uses COTS hardware to build the system. This reduces the risk of 
obsolescence, as upgrades of the hardware are possible. Upgrading obsolete hardware is 
usually cheaper in the long run, compared to maintaining it. COTS hardware also has a 
lower maintenance cost as parts are more easily available. Moreover, COTS hardware is 
usually maintenance free. This means that there is no need to spend on regular 
maintenance to keep the system alive. Therefore, the life-cycle cost of TwiddleNet can be 
kept low. The next version of TwiddleNet will continue to leverage COTS for any 


additional devices. 


15 
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IV. TESTS AND EVALUATIONS 


A. TEST OBJECTIVE 


The test objective is to evaluate the new architecture design of TwiddleNet that 
supports cross-network information sharing. Test setups are derived based on probable 
real-life scenarios and operations in disaster relief works. The testing will verify that the 
new design is able to overcome the constraints of the existing system to share information 
across networks. The testing will also verify that the design is able to function in a multi- 


network environment. 
B. TEST SCENARIOS 


Massive and multiple disasters have struck the central coast area. Monterey is 
chosen as the disaster relief headquarters due to the availability of power and 
communication network infrastructures. TwiddleNet is set up in the disaster relief 
headquarters, which is at least 30 miles away from the disaster sites. The first responders 
from various agencies are tasked to assess the severity of the situations at different 
locations. Only a basic network infrastructure is established at various disaster sites. The 
first responders, equipped with the TwiddleNet clients, are dispatched to different 
disaster sites. Numerous pictures of the frontline situations are captured and disseminated 
using those clients. Planning and resource prioritization are then based on the assessment 
of the real-time information shared. The system is configured as shown in Figure 3 to 


support this operation. 


Under this scenario, the Command Center and Portal will be set up in a disaster 
relief headquarters. The headquarters is likely to be in a location where there are 
electrical power and network infrastructures. As such, the Command Center and Portal 
will be able to ride on this infrastructure to collect real-time contents from the 
TwiddleNet clients at various frontline sites. TwiddleNet clients will have to ride on the 


network infrastructure provided by the remote disaster site to communicate back to the 


rg. 


Command Center and Portal. The three possible ways of communicating from the remote 
disaster site to headquarters include Internet, satellite communication and radio 


communication. 


Existing TwiddleNet is always set up under a single network. This means that the 
Command Center, Portal and clients are all sitting on the same network. This setup will 
not be very practical for the scenario described above. This is because the TwiddleNet 
devices can only operate within the range of a single network. If the capability of existing 
TwiddleNet is extended to operate in multiple networks, it must be able to operate under 
the IP address range provided for each network. As each network is likely to use private 
IP addresses, some form of Network Address Translation (NAT) must be used to allow 
TwiddleNet devices to communicate on different networks. A study of the TwiddleNet 
architecture suggests that COTS solutions can be explored to resolve such issues. In this 
thesis, there are two tests conducted for two types of setups for TwiddleNet under multi- 


network environments. The details of the tests are further illustrated below. 
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Figure 3. | TwiddleNet Configuration to Support Disaster Relief Operations 
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1. Distributed Setup A 


In this setup, it is assumed that local site (Subnet A) and remote site (Subnet B) 
are managed by either a single agency or coordinated agencies. This is because the 
devices in both sites are configured with unique IP addresses. The Dynamic Host 
Configuration Protocol (DHCP) server in each subnet is used to allocate IP addresses to 
devices for each site. The two DHCP servers do not allocate conflicting IP addresses and 
there is no need for network address translation. Figure 3 is an illustration of this setup. 
The purpose for this setup is to verify that cross-network information sharing is 
achievable by configuring a few additional COTS hardware items into the system. The 
configuration uses two wireless access points for two Wireless LANs (WLANs). The two 


WLANS are then connected using a router. 






SubnetA 






“my f0 


SubnetB 














Access Point 
Portal \s 4 a) #7) 
Access Point ae Z 
Wireless Link Wireless Link 
Remote Access 
~ GQ Y re; E Q /DHCP Server 











c d : 
ee Mobile Clients 
Center 


Router 







Mobile Clients 





TwiddleNet Remote Site 


Figure 4. _ Distributed Setup A 


a. Configuration 


Subnet A is configured to represent the setup of TwiddleNet in a disaster 
relief headquarters. The setup is comprised of the Command Center, Portal and a few 


mobile clients. Subnet B is configured to represent the deployment of the TwiddleNet 
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clients at a remote site. The setup assumed that the network infrastructure at the remote 
site is readily available, and that a link is established between headquarters and the 
remote site. This link is simulated in the lab by wiring two access points together through 
a router. The IP addresses for the clients are allocated by the DHCP server at each site. 


The table below shows the IP addresses allocation for the setup. 











192.168.1.254/27 


192.168.1.4/27 





192.168.1.11/27 — 192.168.1.20/27 


10.0.0.0/8 


10.215.175.34/8 


10.215.175.80 to 10.215.175.90/8 


Table 1. | IP Addresses Allocation for Distributed Setup A 


b. Evaluation 

In the test, the process of clients signing on to the Portal and sharing of 
information is exactly the same as the process for single network. The test shows that the 
clients from both subnets are able to logon to the Portal. Clients from Subnet A are able to 
share information to clients at Subnet B and vice versa. The Command Center is also able 
to receive the information from all the clients. Under this setup, every TwiddleNet device 
is required to have a unique IP address. However, this might not be possible in reality. 
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The reason is that there might not have enough IP addresses for all the devices that are 
deployed for the operation. It is also very difficult to manage a large range of IP 
addresses and to ensure that no two devices will end up using the same IP address. To 
resolve this problem and to minimize the impact on the existing network infrastructure, 
each subnet can form a private network with a gateway to interface with other subnets. 


Distributed Setup B is an illustration of such configuration. 


Zz Distributed Setup B 


This configuration uses three subnets. Command Center and Portal are operating 
in Subnet A. TwiddleNet clients are operating in both Subnet B and C. All the 
TwiddleNet devices are using private IP addresses. This means that TwiddleNet device in 
Subnet A can have the same IP address as TwiddleNet devices in Subnet B and C. This 
situation is possible as subnets may be managed by different agencies and each subnet 
may not have enough public IP addresses for all the devices. However, current 
TwiddleNet system does not allow devices to have conflict IP addresses. As the Portal 
need to be able to resolve the IP address and send the messages to the correct clients. The 
new TwiddleNet design provides the flexibility for devices to use common IP addresses 
by using gateways. The primary role of gateways is to perform network address 
translation for the hosts sitting in the private network. In this way, devices in all the 
subnets are able to communicate with each other regardless of whether they are private IP 


addresses. 
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Figure 5. Distributed Setup B 


a. Configuration 


The test setup includes three private networks namely TwiddleNet HQ 


(Subnet A), Remote TwiddleNet I (Subnet B), Remote TwiddleNet II (Subnet C). All 
networks are interconnected via a Hub. 
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192.168.1.0/27 


192.168.1.254/27;10.215.275.33/8 


19216827 
192.168.1.4/27 
192.168.1.3/27 


192.168.1.0/27 
192.168.1.49/27;10.215.175.37/8 
192.168.1.50/27 

192.168.1.11/27 


192.168.1.0/27 
192.168.1.100/27; 
10.215.175.100/8 
192.168.1.51/27 
192.168.1.11/27 


10.215.175.3/8 


10.215.175.41/8 


LO21S.175: 1010/8 


IP Addresses Allocation for Distributed Setup B 


Evaluation 


With the implementation of the three gateways, all Subnet A, B and C 


hosts are able to communicate even they are sharing the same IP space. All private IP 


addresses are translated into unique IP addresses as shown in Table 2. Content sharing 


between the command post in Subnet A and the mobile clients residing in Subnet B and 


Subnet C is achieved successful without any issue. Clients in Subnet B and C are able to 


share information with each other although they have the same IP address. This is made 


possible through the implementation of gateway. 
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3. TwiddleNet Field Trial 


The TWIDDLENT field trial was conducted during the Tactical Network 
Topology (TNT) Evaluation from 17 November 2009 to 18 November 2009 at Camp 
Roberts. The TNT architecture set up at Camp Roberts consisted of three wireless 
networks interconnected by tactical radio link as shown in Figure 6. This provided a good 
environment to test the new TwiddleNet architecture design for cross network 
information sharing. As the tactical radios are able to support data communication 
between two nodes that are located several kilometers apart, the tests would also show 
that the TwiddleNet is able to operate beyond the range of a single network. During this 
trial, tests were conducted for two types of setup to evaluate the performance of 
TwiddleNet data communication through the tactical radio. The details of the trial can be 


found in ANNEX B: TwiddleNet Onsite Trial. 
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a. Setup A 


Command Center, Portal and mobile client B were connected to Subnet 
Area | for this setup. Only Mobile client A is connected to Subnet Area 3. Under this 
configuration, client B was able to communicate directly with Command Center and 
Portal through the same Access Point. However, client A would need to need to go 
through the TNT radio link to reach the other TwiddleNet devices in Subnet Area 1. In 
this test, one picture was taken by client A at one-minute intervals for a total of ten 
pictures. Measurement was then recorded to note the time taken for each of the message 
to reach client B. The result shows that it took 4 to 9 seconds for the alert message to 
reach client B and it took an average of 3.3 seconds for client B to download picture from 


client A. 
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Figure 7. | Network Diagram for Setup A 


b. Setup B 


In this setup, only the Command Center and Portal were connected to 
Subnet Area |. Both client A and B were connected to Subnet Area 3. The purpose of this 
test is to verify that the message sends from client A is able to reach Portal through the 
radio link and client B is able to receive the alert message from Portal through the same 
radio link. The same procedure from Setup A was used in this setup. One picture was 


taken by client A at one-minute intervals for a total of ten pictures. The result shows that 


Zo 


it took 3 to 8 seconds for the alert message to reach client B, and it took an average of 1.5 
seconds for client B to download picture from client A. It can be observed that the time 
taken for client B to download picture from client A is much faster in Setup B. This was 


because client B was able to access client A from the same Access Point. 
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Figure 8. | Network Diagram for Setup B 
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V. POSSIBLE ARCHITECTURE FOR FUTURE GENERATION 
OF TWIDDLENET 


A. CONSTRAINTS ON CURRENT ARCHITECTURE 


Connectivity is an essential part of the TwiddleNet. The system requires a stable 
connection throughout the operation of the system. The process of the information 
sharing will be affected if any device is unable to connect to the network. The 
requirement of having all devices to be connected to network at all time is challenging 
when deploying TwiddleNet in the field. This is because there are many factors that can 
affect the connectivity in the field environment. With this as the background, the 


following material describes the challenges when using TwiddleNet. 


1. Launching of Client Application 


In order to use the application on the client, the client has to establish a 
connection to the system. Firstly, it has to be connected to a WLAN and obtain an IP 
address from a DHCP Server or configure with a static IP address manually. Secondly, 
there is a need to make sure that the Portal is connected to the network and the 
applications on the Portal are running. Lastly, the client will need to login to the Portal 
with a User ID and password. Upon successful login, the client application will be able to 
launch. This process shows that there must be an established connection between client 
and Portal in order to launch the client application. Ensuring that client and Portal are 
connected through a single network is easy, as the client and the Portal are collocated at 
the same site. For a multiple networks connection, where client and Portal are located 
hundred miles apart, it may not be so easy . Good coordination and good support between 


sites is necessary to make sure the connection between client and Portal is established. 


2. Using of Client Application 


The client application requires access to the Portal through the WLAN connection 


to perform tasks such as sharing items, un-sharing items and downloading items. If the 
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network is not available or the Portal is not reachable, some of the tasks will not be 
performed properly by the application. In some cases, this may result in the need to 
launch and log in to the application again. As such, the application is highly dependent on 
the availability of the network and the Portal. Therefore, it is necessary to ensure a stable 


connection from client to Portal when using the application. 


3. Sharing of Information 


The clients sharing the information do not know the present of other clients and 
do not check if they have received the information. As such, it is likely that not all the 
clients will have synchronized pictures. The receiving clients also do not know if the 
information they have in the database is the latest, as they do not know if there are 
updates that they failed to receive. For the client to resend the information, it has to 
search for the image in the folder and add it to the Shared List in the application for 
sharing out to other clients. However, the application is unable to selectively choose a 
particular client to send the information to. It can only send the information to a group of 
clients, regardless of whether some of the clients have already received the information 
previously. As such, a resend action may result in some clients receiving duplicated 


information. 


4. Creation of Contents 


The application has a fixed format for creating information for sharing. There is 
no flexibility for the clients to create the contents of the information before sending it out. 
If a fireman captures a picture of the fire situation using a smartphone, he does not have 
the flexibility to insert information about the fire through the application, other than the 
tagging mechanism supported by the system. As such, the information provided by the 
content provider may not be sufficient for the Command Center to make a good 
assessment. In addition, the resolution of the pictures taken by a smartphone may be 
lower than desired. Without further information, a photo may not make sense to the 
Commander. If there is flexibility to insert an additional description with the picture, it 


will provide meaning to the information being sharing. 
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B. MOBILE WEB SERVER (MWS) CONCEPT 


if Operating Concept 


The concept of MWS uses mobile devices such as smartphones to host 
information and function as a Web Server. A computer can then access the information 
from the mobile device by using a browser. The architecture of the MWS has three key 
components: the Browser, the Mobile Device and the Gateway, as shown in Figure 9. 
The Gateway relays messages between Mobile Device and Browser such that virtually 
the Browser and Mobile Device are connected directly. To begin the operation, the 
Mobile Device has to register itself to the Gateway, so that the Gateway is able to know 
the current IP address of the Mobile Device and able to route the requests from the 
Browser to the correct Mobile Device. This means that each Mobile Device operating as 
a MWS must have a unique IP address to register to the Gateway. When someone enters 
the URL to the MWS, the request is forwarded to the Gateway after the DNS resolution. 
The Gateway then inspects the HTTP request header to identify and forward request to 
the correct MWS. In a similar way, the reply from the MWS is sent to Browser through 
Gateway [7]. 








Browser Gateway Smartphone 


Figure 9. Key Components of MWS 
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2. Strengths of MWS Architecture Compared to TwiddleNet 


a. Launching of Application is Straight Forward 


The application does not depend on the presence of a network or other 
devices. This is because the client is a Web Server, and a user can launch the application 
without the need to establish a link. This is crucial to first responders, as critical 
information might need to be captured prior to any form of linkage can be established. 
For example, the medical team might need to start using the application to capture the 
information on casualties upon arrival at the site, before a network is established, so that 
the information can be made available to the Command Center for decision making once 


the network connection is up. 


b. Use of Application is Independent of the Network 


The process of using the application, from beginning to completion, only 
happens on the client. There is no involvement of other devices or subsystems. As such, 
the application is not constrained to the availability of other devices or subsystems. This 
is an important feature for the first responders who are going into a disaster site. The first 
responders are likely to be the first to enter the disaster site, and there is no infrastructure 
to allow them to have a stable data link to the Command Center or Portal. It is not likely 
that the first responders can afford to wait for a network infrastructure to be established in 
order to perform their duty. The MWS allows them to start capturing information even 
without a network. When the network is available later, the information captured can be 
shared to the Command Centre immediately. This feature also allows someone to enter a 
site that has no network infrastructure to capture information using MWS. When he 
returns to the base, or somewhere he can find a network connection, he can start sharing 


the information. Figure 10 illustrates this process of information sharing. 
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Figure 10. Process of Information Sharing for Site without Network 


Cc. Sharing of Information is Simple 


In TwiddleNet, one client cannot request information from another client 
through the application. There is a need to communication with the user of the other 
client using another communication means (e.g., voice channel) to request for 
information. For MWS, a client can request information from another client by entering 
the Uniform Resource Locator (URL). There is no need for the user of the other client to 
be in the loop to share the information. In this process, the information that is received 
will always be the latest from the contents provider. As such, there is no risk of making 
decisions with outdated information. Any client can always request updated information 
from any other client at anytime. Unlike TwiddleNet, other systems can also access to the 


clients for information, instead of just the Command Center. 
d. Creation of Contents is Flexible 


Every mobile device running MWS is functioning as a Web Server, and 
every user is an administrator to his mobile device. The user has the administrative rights 
to put in or take out data from the Web page. He is not restricted by the format of the 
contents he wishes to share. This is an important feature for the first responders in some 


situations, and the formatted messages are not sufficient to represent certain important 
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information. For example, a fireman may want to share information about the condition 
of the forest fire and the direction that the fire is spreading. This can be a piece of 
important information to his fellow firefighters working in that direction. This 
information is also important to the Command Center for making decisions to send 
reinforcements to the right location. When information is limited to pictures alone, the 


information is insufficient. 


3 Shortcomings of MWS 


Since every client running as MWS is a Web Server, the information is contained 
inside the client. If client B had access to client A before,, it has to access client A again 
if it has to view the information again. This is similar to access NPS’s Web Server to 
view the homepage. One must access NPS’s Web Server again, if there is a need to see 
the homepage again. However, an MWS uses a mobile device and does not have the 
same capability as a normal Server. If all the other mobile devices are accessing the same 
mobile device, this mobile device may be too overwhelmed to handle the load. Even if 
the mobile device is able to handle the load, its battery life will be shorter as it has to 
perform more transmission tasks to reply to the requests. Another shortcoming of the 
MWS is that there is no application that reads and combines information from all the 
mobile devices into a page of information. A user will have to access each one of them, 
one at a time, to see the full picture. This may not be a problem if there are only a few 
mobile devices deployed, however, it can be a very tedious task to continue accessing 
ten, twenty, or more of such devices. Finally, the MWS does not have a feature to cache 
information that was last accessed. If a particular mobile device becomes unavailable, its 


past data will not be available for referencing in another location. 
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Figure 11. Shortcomings of MWS 


tc TWIDDLENET ARCHITECTURE USING MOBILE WEB SERVER 


There are many good features in MWS architecture that TwiddleNet can use to 
overcome some of its shortcomings. A Proposed Architecture of TwiddleNet is as shown 
in the figure below. There are three key components in this architecture: the Command 
Center, Gateway and TwiddleNet Clients. The functions of each component are described 


below. 


a2 





Command Center Gateway 





TWIDDLENET Clients 


(MWS) 
Figure 12. TwiddleNet Architecture using MWS 
1. Command Center 
a. Combine Clients’ Information into a Single Web Page 


The Command Center has a service that organizes all the information 
collected from the clients into a single page view as shown in the figure below. The 
Service keeps track of the updates from each client and then updates the respective 
column and row on the webpage accordingly. The Command Center serves the 
Commander with a comprehensive picture for decision making. At the same time, it also 
serves other systems, and TwiddleNet clients, as a web server. A client is able to 
selectively choose to see any other client information from the Command Center. For 
example, client B is unable to access client A directly. It can then choose to access the 
Command Center for client A’s information instead, since the Command Center keeps an 
updated copy of information from client A. If only client A’s information is requested 
from the Command Center, only client A’s information will be provided to client B. This 


is to make sure that the bandwidth of the network is better utilized. 
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Figure 13. Webpage of Command Center 


b. Caching of Clients’ Information 


The Command Center has a service that caches the information from the 
clients. This is to prevent unnecessary overloading of the network and the clients by 
minimizing constant access to clients. It also serves as a redundancy to the clients in the 
event that they became unavailable or overloaded. The service from the Command Center 
will pull the information for the client when it receives an update message from that 
client. This is similar to receiving an alert message in TwiddleNet. After the service pulls 
the information from the client, it stores it in the database and updates the webpage 
accordingly. The service also has the option to poll the information from each client at an 


interval such that it will not overload the network or the clients. 
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2. Gateway 


The Gateway operates the same way as the gateway in the MWS. It relays the 
messages between a Requester and a Sender. When each client is connected to a network, 
it has to register its IP address with the Gateway; when client A enters the URL to client 
B, the Gateway will be able to resolve the IP address of client B and relay the messages 
between client A and B. The Gateway also keeps track of the active and inactive clients, 
such that if there is a request sent to an inactive client, the Gateway will be able to 
respond to the Requester immediately, instead of searching and waiting for timeout 


before informing the Requester that the client is inactive. 


3. TwiddleNet Clients 


a. Information Owner 


The application on the client is able to generate information onto a 
webpage, using a template to minimize the steps required to share the piece of 
information. The application also has the flexibility to allow specific information to be 
updated into the webpage to make it more meaningful. When the webpage is first created 
or subsequently updated, a broadcast message will be sent to the network. The Command 
Center and other clients that receive this message will request the information from the 


information owner. The process of information sharing is as shown in the figure below. 
b. Information Requester 


When a client receives a broadcast message from another client informing 
of an update of information, it can choose to access the information if it is available. The 
client should have a caching capability such that the accessed information is stored 
locally for subsequent reference. The client should also have the option to request 
information from either the Command Center or the information owner (another client). 
In this way, neither the Command Center nor the information owner will become a 
bottleneck or single point of failure. By default, the client requesting information should 
access the Command Center so that it will not overload and drain the battery of the 
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information owner. If the Command Center is not available, it can then access the 
information owner directly. As such, the Command Center and Information Owner will 


serve as redundancies to each other. 
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Figure 14. Process of Information Sharing 
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VI. CONCLUSIONS 


TwiddleNet is an excellent system for first responders who are supporting 
humanitarian aid and disaster relief operations. It is portable and can be deployed 
quickly. The mobile client is also a very handy tool for the first responder to capture and 


share information to the Command Center in near real time. 


On the other hand, the architecture of TwiddleNet is designed and tested to 
operate on a single network, which limits its range of operation to that of the network. 
Thus, it will be inadequate for the system to support large events, such as the occurrence 


of a major disaster. 


Typically, multiple sites will be deployed when there is an operation that spans a 
large area. A network can be set up at each site to support the systems operating there. 
Each individual network can then be connected through the Internet, Satellite 
Communication or Radio Communication. The thesis is based on this idea of a multiple- 
network deployment in designing TwiddleNet to function in a multi-network 
environment. Tests were conducted in the lab and in the TNT field trial. The results show 
that the new TWIDDLENT architecture is able to support multiple networks; hence its 
range is no longer constrained to that of a single network. Instead, it is extended to the 
coverage of the Satellite Communication or the range of the Radio Communication. This 
is a significant improvement to TwiddleNet capability. TwiddleNet is now able to be 
deployed effectively to support humanitarian aid and disaster relief operations. With this 
extended capability, TWIDDLENT can potentially be used to support Hot War and 
Operations-Other-Than-War. It can be used to collect intelligence pictures and own force 


situation pictures at near real time. 


The thesis also conducted a study of the Nokia Mobile Web Server to propose a 
new architecture of TwiddleNet. The MWS uses mobile devices to operate as a Web 
Server. Such a design allows mobile devices to run applications in the absence of 
network connectivity. In the case of TwiddleNet, no application can be launched without 


network connectivity. The drawback of the MWS is that it does not have a Command 
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Center that consolidates the shared information from all the clients into a single webpage. 
This study combined the strengths from both the MWS and TwiddleNet, and proposed an 


architecture for the next generation of TwiddleNet. 


The capability of TwiddleNet in performing cross network information sharing 
had been demonstrated in lab and field trial. It is suggested to conduct tests involving 
actual users during field exercises to verify the performance of the system, so that the 
system may be used for operations in future. It is also suggested to develop a prototype 
using MWS to verify the new architecture for next generation of TwiddleNet. This new 
architecture is expected to improve the flexibility, efficiency and redundancy of 


information sharing. 
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APPENDIX A — VARIOUS TWIDDLENET COMPONENTS?’ ROLES 


Portal 

The primary function of the Portal is to serve as a gateway to a network of mobile clients. 
A central repository of metadata that describes the shared content is housed in the Portal. 
The Portal tracks and stores all IP information of the currently signed-in clients as well. 
Command Post 

A Command Post is a modified TwiddleNet mobile client that acts as a situational 
awareness tool. It is capable of downloading and displaying shared contents from any 
mobile client. 

Lab LAN 

Lab LAN includes a router that is configured to route IP traffic between two Subnets. 
Access point 

Each Subnet will incorporate an access point to provide wireless access for all wireless 
Subnet devices. 

DHCP Servers 

IP address management and allocation are done by DHCP servers. 

Mobile Clients 

TwiddleNet mobile clients can come from different groups, namely medics, firefighters 
and police. At least one client is included in each Subnet. Content sharing is then tested 
between mobile clients residing in different networks. 

TwiddleNet Gateway 

The gateway’s primary role is to provide Network Address Translation for the 


TwiddleNet Private Network clients. Static NAT is implemented in DTS-B. 
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APPENDIX B - TWIDDLENET ONSITE TRIAL 


A. INTRODUCTION 


TwiddleNet is a hardware/software suite designed for use by agencies assisting in 
recovery efforts after a natural disaster or an emergency of any sort. Its main purpose is 
to quickly and automatically provide content sharing of pictures of important aspects of 
recovery efforts, to all users logged on to the TwiddleNet system, through the use of 
smart phones, a Portal and a Command Center. The majority of previous tests involving 
TwiddleNet have centered around operating the architecture on one network/subnet, and 
in this regard, the application runs very effectively. Operating in this manner could, 
however, in certain situations, limit the effective distance that users can be from one 
another, as one wireless network will not usually cover an entire area, organizations 
would have to be separated in their recovery efforts. To address this potential limitation, 
tests involving operating on more than one wireless network are necessary to solidify the 


utility of TwiddleNet 
B. OBJECTIVE 


As stated, prior testing with TwiddleNet has centered on operating on only one 
network, which will, in all likelihood, be insufficient in a real world rescue situation. The 
tested ability to operate on more than one wireless network would greatly enhance the 
utility of TwiddleNet in real world situations. The architecture set up at Camp Roberts, 
utilizing three wireless networks interconnected by tactical radio, provided the perfect 
opportunity to test TwiddleNet in this manner. The range of the tactical radios, several 
kilometers, would effectively extend the operating range of TwiddleNet to the same 
range, and the tested objective of our experiment is for a mobile device on one of the 
three wireless networks to pass data (pictures) through the gateway to the Command 
Center on another wireless network, and subsequently on to a different mobile device on 


a third wireless network. 
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C. RESULTS 
1. Test Case 1 


This test case has a Command Center, Portal and mobile client B connected to 
Subnet Area 1. Only Mobile client A is connected to Subnet Area 3. The configuration is 
as shown in Figure 1. The purpose of this test case is to verify that pictures captured and 
sent from a mobile client in the subnet are received by the mobile Client and Command 
Center on the other subnet. This test will require mobile client A to capture and send 
pictures across the TNT network at one minute intervals for a total of ten pictures. The 


measurement taken for this test case is shown in Table 1. 
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Figure 1: Configuration for Test Case 1 
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Pic. Subnet Areal Does the Command 
No. Center receive and 
post the picture on 
Does the Client | Time Taken for | Is the Client able to | Time Taken for | the webpage? 
receive the alert | Client to | download the | Client to | (Yes/No) 
message? receive picture successfully? | download 
(Yes/No) message (Yes/No) picture 
(seconds) (seconds) 
1 Yes 9 Yes 3 Yes 
2 Yes 4 Yes 3 Yes 
3 Yes 4 Yes 4 Yes 
4 Yes 4 Yes 3 Yes 
5 Yes 5 Yes 3 Yes 
6 Yes b) Yes 3 Yes 
7 Yes 5 Yes 4 Yes 
8 Yes 4 Yes 3 Yes 
9 Yes 5 Yes 3 Yes 
10 Yes 5 Yes 4 Yes 




















Table 1: Measurement for Test Case 1 


2. Test Case 2 


In this test case, only the Command Center and Portal were connected to Subnet 


Area |. Both mobile clients A and B were connected to Subnet Area 3. The purpose of 


this test is to verify that the messages sent from mobile client A reach the Portal through 


the radio link and mobile client B is able to receive the alert message from the Portal 


through the same radio link. The same procedure used in Test Case 1 was used in this 


test. One picture was taken by client A at one minute intervals for a total of ten pictures. 


The measurements taken for this test case are as shown in Table 2. 
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Pic. Subnet Area3 Does the Command 

No. Center receive and 
Does the | Time Taken for | Is the Client able to | Time Taken for | post the picture on 
Client receive | Client to | download the | Client to | the webpage? 
the alert | receive picture successfully? | download (Yes/No) 
message? message (Yes/No) picture 
(Yes/No) (seconds) (seconds) 

1 Yes 8 Yes 2 Yes 

2 Yes 3 Yes 1 Yes 

3 Yes 4 Yes 2 Yes 

4 Yes 4 Yes 2 Yes 

5 Yes 5 Yes 1 Yes 

6 Yes 4 Yes 2 Yes 

7 Yes 5 Yes 1 Yes 

8 Yes 5 Yes 1 Yes 

9 Yes 4 Yes 1 Yes 

10 Yes 4 Yes 2 Yes 























Table 2: Measurement for Test Case 2 
D. ANALYSIS 


There are two types of messages that are transmitted in the TwiddleNet system. 
The first type of message is the Alert message. The Alert message contains the Meta data 
of the picture captured by the mobile client and is used to broadcast to clients that are 
subscripted to it. The second type of message is the image file. This image file can be 
downloaded from the content provider to the clients that have received the alert message. 


Figure 3 shows that the time taken for Client B to receive the Alert Message is about the 
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same for both test cases. This is because the Meta data is only a few kilobytes and it does 
not cause a significant delay when transmitting through the TNT radio link. However, 
Figure 4 shows that the time taken to download the picture is about double for Test Case 
1 as compare to Test Case 2. This is because the size of the image file is a few hundred 
kilobytes. However, the timing for Test Case 2 is still acceptable, as the average time 


taken is only 3.3 seconds. 
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Figure 3: Time Taken to Receive Alert Message for Test Cases | and 2 
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E. ISSUES ENCOUNTERED 


As in any test that involves the complicated configuration of equipment and a 
constricted timeline, a failure in any of an assortment of areas would have a negative 
impact on our ability to complete a test that would prove the ability of TwiddleNet to 
Operate over more than one wireless network. We had scheduled 17 and 18 of November 
for our testing with the actual conduct of our test expected to only take approximately 
two, hours under moderately stable conditions. Upon arrival and due to the limited 
experience that the operators of the tactical radios had (the radios had just recently been 
released), the radio network upon which our plan depended was not operational. This 
restricted our testing on the 17th to only operating on one wireless network. This did 
give us a chance to operationally check our equipment after transporting it over one 
hundred miles, but did not allow us to evaluate anything that TwiddleNet hadn’t already 
shown it was able to perform. Difficulties with the radio network continued until early in 
the afternoon on the 18th (the day we planned to leave), and in the interim, we attempted 
to construct a wired network that would simulate what we had planned to operate under 
with the use of the tactical radios. This effort proved to be very difficult as we were 
competing with a simultaneous effort that continued its efforts to troubleshoot the radio 
network, and our wired efforts were continually interrupted in deference to testing the 


radio network. 


Early in the afternoon of the 18", the radio network became operational and at 
this point we were able to begin attempts to evaluate our testing. The initial plan was to 
use three subnets for the testing. The system, however, was unable to communicate 
through the Subnet Area 2 access point, possibly due to the incompatibility of the 
TwiddleNet data communication with the wireless access point. Due to time constraints, 
at this time we changed the test plan to perform the testing using only Subnet Areas1 and 
Area 3. These efforts proved viable and our results and conclusions are based on testing 


that utilized two wireless networks. 
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F. CONCLUSION 


Our original test, as scripted, called for the transfer of communication across three 
different networks. The design of the test, however, was formulated based on the 
architecture at Camp Roberts. The real objective of our testing was to verify that 
TwiddleNet could simply perform content sharing across TWO networks. Our testing in 
this regard was successful and the test data supports this. Had the radio network at Camp 
Roberts been operational earlier, or if our team had more time to troubleshoot our issues 
with the third network, it is very likely that the test could have been performed 


successfully as designed. 
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